The AGA Experience 3/AGA Experience Volume 3 (1997)(NFA - SAdENESS)[!].iso/software/utilities/misc/atebeta5b/source-code/atebeta5source.readme

Text File | 1996-05-05 | 10.6 KB | 224 lines

6 MAY 96

This source is a public release to Aminet and is for the Amiga
Typeface Engine Beta5B, also available now on Aminet.  This is
now freely distributable code, superceeding any previous
restrictions.

Now with the preamble out of the way let me get one request out:

I may still work on ATE from time to time.  In particular I want
to finish the AFM corrector, unless you have a better alternative.
If you want to add a feature, check to see if I didn't do it first.
It'll save you a whole lot of trouble re-inventing the wheel. :)

_______Archive contents:

ATEbeta5B.c           Latest version of source code, includes
                      patch for NewScaledDiskFont().  This is
                      the main engine and is essentially finished,
                      except for replacing the dumb console
                      window with nice AutoRequesters.  This works
                      with all versions of post.library from V15,
                      including HWGPOST.  You will need to swap
                      the "hwgpostlib.h" with "postlib.h" if you
                      are using the old headers from Pre-V22 POST.

ATMbeta1A.c           A very old, practically unreleased, version
                      of the source that used a routine in
                      PostScript, instead of AFMs, to obtain the
                      character dimensions.  Using AFMs is
                      far better, but AFMs may be inaccurate or
                      missing font bounding box info.  Notice also
                      PS mistakes I corrected in ATEbeta5.  Use
                      this version to learn how to extract character
                      bounding boxes without AFMs if you wish, and
                      don't be afraid to make your own AFM corrector.

FixAFM.c              A shell of code that initalizes the PS library
                      for preparation of reading bounding box info.
                      Use this combined with code from ATMbeta1A to
                      make your own AFM corrector.

atmDevLog.txt         My development log from the very first day I
                      got my copy of DICE C 3.0.  Notice that all
                      the source code here works on DICE C 3.0 or
                      better, and the patches use registerized
                      parameters for the patch functions.  This will
                      require translation to SAS C if you use this
                      instead of DICE.

ATEbeta5GUI.gui       A user interface I designed using GadToolsBox
                      version 2.0b.  If you want to redo it from
                      scratch that's up to you.  However, YOU MUST
                      AVOID M.U.I. AT ALL COSTS!!!!!!  This thing
                      runs on a 68000 and I want it to stay that way!

Now for some details:

________Registerized Parameters

As I wrote above, this code works compiled with DICE 3.0.  The patches
work by using registerized parameters and making sure the library base
is in A6 before calling the original function.  I find this works
very well and reliably, even for the otherwise risky Text() patch.
DICE code generators automatically save D2-D7 and A2-A6 before running
the actual function, and restore these registers before returning,
and automatically return any results or pointers in D0.  Very handy!

Also regarding the patches, I have all PostScript processing occur in
ATE's main process, such as not to over-load any programs that call on
the patched functions.  I use EXEC messages for this and global pointers
to the message ports.  This is critical especially for the Text() patch
where many non-Processes call upon it, and I can only make AmigaDOS calls
from within Processes.  This may appear to bog down the PostScript engine
but it manages to run quite smoothly.

_______Big Problem Patch

One patch has turned into a nightmare; the AvailFonts() patch.  This one
actually inserts ATE TextAttr structs inside the memory space set up by
the program's caller.  The logic works like this:

0) (Before patching) ATE finds out how much space a AvailFonts() call
   would take for diskfonts, then remembers that value

1) Program calls AvailFonts() with its buffer and settings

2) ATE determines if the caller's buffer is big enough (including for
   already-loaded fonts and ROM fonts) and if it's not big enough,
   return the # of bytes extra needed.  Some programs deliberately
   call AvailFonts with a zero length buffer causing a font scan to happen
   twice.  ATE may otherwise cause three or four font scans if I did not
   pre-determine the disk font size.

3) ATE calls the original AvailFonts fcn with the buffer somewhere in
   the middle of the caller's buffer, like this:

|-dfheader-|-ATE reserved-|-AmigaDFheader-|-AmigaFonts-|-ATE reserved-|

4) ATE counts the number of Amiga diskfonts and builds a new dfheader,
   then inserts ATE fonts at the start of the list, and the text for the
   font names at the end:

|-dfHeader-|-ATEfonts-|-AmigaFonts-|-ATEfontnames-|

5) ATE returns a zero indicating success.

This technique works with many programs, but it fails with these:

DeluxePaint IV non-AGA: Some Amiga diskfonts are missing at the end

FED 1.3 (Old font editor): Many font names are destroyed

Apparently, also Final Copy/Final Writer crash instantly on startup
with this one patch active.

I tried to account for both TTextAttrs and TextAttrs (With pre-defined
tags for ATE fonts) and I know that Excellence! 3.0 and asl.library
font requesters work with this, showing all fonts.  I cannot tell
why DeluxePaint IV non-AGA is the only program that doesn't like it.

_________Having PostScript code call ATE

Only functions called by post.lib's callextfunc operator require
stack-based calls.  Later on, if you choose to make PS code call
functions within ATE, use Heinz Wrobel's @calluserhook operator and
create a Hook structure, using a registerized function as an entry
point.  This will be important with any AFM corrector written once
Heinz eliminates callextfunc.  Check out the old ATMbeta1 source for
calextfunc examples.

Currently, no code in ATE uses this operator, to avoid problems once
Heinz finally removes it.  Any AFM corrector will need to use
@calluserhook to grab glyph dimensions.

_________Using AFMs to speed up the process

ATE pre-determines how much memory a bitmap will take based on the
font size selected, and each character's dimensions, based on its
AFM's contents.  Adrian Aylward's old MKBMAP program, which ATE was
based on, obtained this right from the typeface itself.  I use AFMs
because of reduced processing time needed (why reproduce what's already
available?) and to improve the kerning of italicized typefaces.  Check
out Times-Italic, type a few lower case "f"s and "g"s and see for yourself.
This kind of manipulation will be critical for "script" typefaces and
other spacing-picky typefaces.

How much space a character is SUPPOSED to take is determined by the WX
value in a given metric.  The Amiga equivelant is the tf_CharSpace array.
This information only exists in the metric file and NOWHERE ELSE.
Not even in the typeface itself.

Characters may overlap in front of, or behind, its designated space.
PostScript uses an arbitrary scale of 0 to 1000 to define a character's
"living space".  Characters may exceed this by design and you will
notice this with negative numbers, or numbers greater than 1000, in
a metric's B values (B xxx xxx xxx xxx).  On The Amiga, characters
like this will have wider dimensions in the tf_CharLoc array, than its
tf_CharSpace value.  It will also have a tf_CharKern value appropriate;
negative if it "hangs" left (like a lower case italic f) or positive if
it has leading spacing (not likely in most typefaces).

ATE will reserve just enough memory for each character.  If the AFMs are
inaccurate, you might notice pieces of one character intruding on
another.  This is where AFM accuracy is critical!  Typefaces from Adobe
Systems will have accurate AFMs, as ATM for The Macintosh relies on this
info as well!  Typefaces from third parties, or from Windows packages,
will have inaccurate AFMs, or PFMs that don't include B parameters.
(OK so I lied.  Metric info is stored on Macs in a FOND resource which
is a binary copy of what's in the AFM file.)

Somewhere on The Internet exists a program called "pfm2afm" which
generates a text AFM file out of an MS-Windows PFM file.  PFMs contain
much of the info ATE needs except the bounding boxes!  This is one
reason why an AFM corrector is necessary.  The program was originally
written for IBM OS/2, but an Amiga version exists.  Ask me if you can't
find it.  I didn't include it here because of copyrights.

Since a great deal of PostScript typefaces come with PFM files instead
of AFM files (or come with inaccurate AFM files) converting one of these
metric files becomes a two step process; Convert the PFM to an AFM, then
correct the new AFM based on the typeface itself.

________Ideas for a Typeface Installer

A typeface installer should look for PFMs and AFMs when installing
typefaces.  It should be able to search an entire floppy disk or CD-ROM
for these files.  The matching typefaces will either have an extension
of .PFB, .PFA, or no extension at all.  It is possible to issue a LIST
command at a CLI like this:

List CD0:#?.PFM ALL >T:listFile.txt

The list file will give a breakdown of the directory structure and all
the requested files within.  You can then determine where the typefaces
are by using the filenames of the .PFM or .AFM files.

The installer can then perform any conversions or corrections needed
and generate a _ATE_#? file for it.

A typeface installer should also be able to group typefaces into families.
AFM files contain family info and should help match typefaces together.
Adobe relies on this for ATM for The Mac and for Windows.  A family
includes its "normal", "Bold", "Italic", and "BoldItalic" cousins.
For typefaces that have more than two weights, like Adobe Garamond, you
can create additional groupings.  Worst case, if you can't account for
various weights, is to pair off typefaces as "Regular" and "Italic"
and have a font entry for each weight.

________That's it

I so much wanted to turn this into Adobe Type Manager for the Amiga,
but Adobe wouldn't allow it.  As such it turned into Amiga Type Engine
but it is an unfinished beast.  Try to make this as much ATM as you
can, and draw ideas from Adobe's product.  Their README files for their
Windows product can give you needed insight into its operation.

Also remember you're depending on another coder's PostScript library
to do this, this is so you can use more than just Type 1 typefaces
or whatever.  ATE will end up being as good as the PostScript library
is, so don't be afraid to bug Heinz Wrobel for improvements. :)

Gordon Fecyk